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SPECIFICATION 
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AUTHENTICATION METHOD 
TECHNICAL FIELD 

5 

The present invention generally relates to communication networks comprising mobile nodes 
and in particular to Mobile Internet Protocol (M1P) authentication. 

BACKGROUND 

10 

Mobile IPv6 (MIPv6) capable mobile nodes, such as cellular phones, laptops and other end- 
user equipment, can roam between networks that belong to their home service provider as 
well as others. Roaming in foreign networks is enabled as a result of the service level and 
roaming agreements that exist between operators. One of the key AAA protocols that 
15 contribute to making this kind of a roaming mechanism possible is Diameter and the general > 
architecture for MIPv6 AAA is schematically illustrated in Fig. 1. 

Finding a well-functioning and complete MIPv6 AAA solution combining mobility with 
authentication/security for mobile communication would be very desirable. For instance, 
20 AAA can then be used to check/control who is entering the network. However, in the prior art 
only partial solutions are presented. These arc generally non-consistent with each other and do 
not work end to end. 

\ 

In (4] t for example, attempts are made to specify a new application to Diameter enabling 
25 Mobile IPv6 roaming in networks other than the home domain. The Internet draft identifies 
information that typically needs to be exchanged between a MN and an AAA Client in the 
network and suggests use of the new Diameter application in exchanges of this information 
between AAA Client and AAAv, between AAAv and AAAb, and between HA and the AAA 
infrastructure. However, no particular mechanism to convey information between the mobile 
30 node and the AAA Client is specified. This, together with other shortcomings, makes this 
solution unsatisfactory and non-complete. 

Thus, the need for an appropriate mechanism for MlPv6 AAA remains. 
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SUMMARY 

An object of the invention is to achieve a complete mechanism for combining terminal 
5 mobility and user authentication in networks with mobile nodes. Another object is to enable 
MlPv6 AAA. 

This is^achieved by means of a new EAP authentication protocol referred to as u EAP/MIPv6" 
(or u MIPv6 authentication method'*). Preferably, the invention enables MIPv6 AAA by using 
10 a' combination of PANA and Diameter as carrier protocols. The EAP/MIPv6 protocol can * 
carry information that facilitates MlPvg authentication, as well as dynamic MN home address 
allocation, dynamic HA allocation, distribution of security keys between HA and MN, and 
distribution of security keys between PAC and PAA for PANA security. 

15 PANA is preferably used in carrying EAP/MIPv6 between MN/PAC and PAA/AAA Client. 
There are alternative carrier protocols, though. Diameter EAP Application [3J is generally 
used to transport EAP/MIPv6 between PAA/AAA Client and AAAv, and between AAAv and 
AAAh. The Diameter protocol is also used by AAAh for assignment to PAA/EP of security 
keys for PANA security, optional MIP packet filters via MIP filter rules, and optional QoS 

20 parameters etc. However, there may be embodiments using another suitable AAA protocol, 
such as Radius, instead of Diameter. 

The exchanges between HA and the AAA infrastructure may for instance follow the AAAlv 
HA interface protocol specified in Diameter MIPv4 Application [2], or alternatively employ a . 
25 mechanism similar to that currently used in 3GPP2 (i.e. [9]) in conjunction with the IKE [8] 
framework. 

MIPv6 handofls use a subset of the procedures used for MIPv6 initiation. For the handoff 
case, EAP/MIPv6 would only need to carry information that facilitates MlPv6 authentication, 
3 0 and distribution of security keys between PAC and PAa for PANA security. 

For die case where EAP is used for WLAN authentication, e.g., EAP/AKA, PANA can be 
used for transporting EAP/AKA between PAC and PAA for WLAN access authentication 
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instead of [10]. By carrying multiple EAP sequences in a single PANA sequence, both 
EAP/AKA authentication of WLAN and EAP/MIPv6 can take place within a single PANA 
sequence for optimization purpose. 

5 According to the authentication method of the invention, new EAP TLVs are defined for 
carrying MIPv6 authentication information. In case MDS challenge authentication is used, 
these typically includes a MDS Challenge attribute and a MDS Response EAP-TLV attribute. 

The authentication protocol preferably defines a number of additional EAP TLVs for dynamic 
10 MN home address allocation, dynamic HA allocation and distribution of security - keys 
between HA and MN. These attributes are optional and there may be implementations lacking 
some or all of them. Furthermore, for distribution of security keys between PAC and PAA for 
PANA security, a PAC-PAA Pre-shared Key Generation Nonce EAP-TLV attribute is 
generally needed. 

15 

By means of the attributes like these, the EAP protocol is allowed to cany MIPv6-re!ated 
auxiliary information, such as requests for dynamic MN home address allocation, dynamic 
Home Agent allocation, as well as nonces/seeds for creation of necessary security keys, in 
addition to the main IPv6 authentication infonnation. This is a major advantage of the 
20 invention. 



BRIEF DESCRIPTION OF THE DRAWINGS 



The invention may best be understood by reference to the following description and the 
2 5 accompanying drawing, in which: 

Fig. 1 is a schematic view of a communication system for MIPv6 AAA in which the 
present invention may be used; 

30 Fig. 2 is a signal flow diagram of MTPv6 initiation in accordance with a first exemplary 
embodiment of the present invention; 

Fig. 3 is a signal flow diagram of MlPv6 initiation in accordance with a second exemplary 
embodiment of the present invention; and 
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Fig. 4 is a signal flow diagram of MIPv6 handoff in accordance with an exemplary 
embodiment of the present invention. 

DETAILED DESCRIPTION 

introductory discussion 

As mentioned in the background section, a proposal which attempts to specify a new 
application to Diameter that enables Mobile IPv6 roaming in networks other than its home has 
been raised in IETF [4]. It identifies the following information that typically needs to be 
exchanged between a MN and an AAA Client in the network: MIP Feature Data, EAP Data, 
Security Key Data, and Embedded Data. It also specifies the use of the new Diameter 
application in exchanges of the above information between AAA Client and AAA V , between 
AAAv and AAAh, and between HA and the AAA infrastructure. 

Although [4] does not specify any particular mechanism to convey information between the 
mobile node and the AAA Client, the possibility to use the protocol defined by the IETF 
PANA WG has been mentioned. On the other hand, the PANA WG has recently identified 
EAP [6] as the payload for the PANA protocol and carrier for authentication methods [1]. In 
other words, PANA will carry EAP, which can cany various authentication methods. By the 
virtue of enabling transport of EAP above IP, any authentication method that can be carried as 
an EAP method is made available to PANA and hence to any link-layer technology. The 
PANA WG has assumed a clear division of labor between PANA, EAP and EAP methods. 
Defining new authentication methods, or deriving/distributing keys is considered outside die 
scope of PANA. Providing a secure channel that protects EAP and EAP methods against 
eavesdropping and spoofing is also not an objective of the PANA design. 

This implies that apart from carrying the EAP, the PANA protocol will not be able to 
transport the other MDPv6-related auxiliary information such as MIP Feature Data, Security 
Key Data, and Embedded Data. Thus, there is no satisfactory prior-art mechanism for MIPv6 
roaming in foreign networks and conveying necessary information between MN and AAA 
Client 
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) 

Another drawback of the solution in [4] is that it requires the AAA Client (and AAAv) to 
understand the authentication method and be aware of the contents of the exchanges (MIP 
Feature Data, EAP Data, Security Key Data, and Embedded Data) between the MN and the 
AAAh. It will not be possible to let the AAA Client act as mere pass-through agent, which is 
5 one of the major advantages of using EAP (and one of the assumptions for using PAN A). 
Neither will it be possible to apply prior encryption between MN and AAAh (e.g., EAP/TTLS 
[5]) and the exchanges will be visible over the air interface. Security against eavesdropping, 
xnan-in~the-middle and other attacks is likely to be compromised. 

10 These drawbacks and others are overcome by the present invention, according to which an 
EAP authentication protocol is proposed for combining the terminal mobility of MIPv6 with 
the user authentication of AAA in a most advantageous way, achieving a complete MTJPv6 
AAA solution. 

15 Main principles as well as implementation details of the invention will now be described by 
way of example. General reference is made to the MIPv6 AAA actors and architecture 
illustrated in Fig. 1. 

MIPv6 AAA using PANA and Diameter Combination 

20 A new EAP authentication protocol u EAP/MlPv6" is defined to carry a "MIPv6 
authentication method". EAP/MIPv6 should enable negotiation/enforcement of MIPv6 
authentication (main goal), as well as support some auxiliary information that facilitate eg., 
dynamic MN home address allocation, dynamic HA allocation, distribution of security keys 
between HA and MN, and distribution of security keys between. PAC and PAA for PANA 

25 security. PANA is preferably used in carrying EAP/MIPv6 between MN/PAC and PAA/ AAA 
Client. Alternatively, carrier protocols which satisfy EAP requirements on lower layer 
ordering guarantees as in PPP and [10] may be used to carry EAP/MIPv6 between the MN and 
AAA Client Specifically for the 3GPP2 CDMA2000 case, it is possible to cany EAP/MIPv6 
between the MN and AAA Client using PPP Data Link Layer protocol encapsulation with 

30 protocol field value set to C227 (Hex) for EAP [6J. 

A preferred embodiment uses Diameter for communication between the AAA client and home 
server Beyond the PAA/AAA Client towards and within the AAA infrastructure, Diameter 
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EAP Application [3] is then used to encapsulate EAP/MIPv6 within Diameter, that is, 
EAP/MIPv6 is carried between the PAA/AAACIient and AAAh. The Diameter protocol is 
used by AAAh for optional assignment of MIP packet filters via MIP filter rules to the 
PAA/EP and HA, which correspond to the filter enforcement points. The Diameter protocol is 
5 also used by AAAh for distribution of security keys to PAA for PAN A security, and optional 
signaling of QoS parameters etc. 

It should be noted that even though Diameter is the preferred choice, it may sometimes be 
appropriate to instead use another AAA protocol* such as Radius, with modifications obvious 
10 to the man skilled in the art. 

Regarding the communication between HA and the AAA infrastructure for exchange of 
security keys (necessary to establish SA between HA and MN) and accounting, two 
possibilities are suggested. One possibility is to employ the AAAh-HA interface protocol 
15 specified in Diameter MDPv4 Application \2). Another possibility is to employ a mechanism 
similar to that currently used in 3GPP2 (Le. [9]) in conjunction with the IKE [8] framework, 
to distribute dynamic pre-shared keys between MN and HA. A KeylD is used by the HA to 
retrieve (or generate) the HA-MN pre-shared key from the AAAh (exactly how this is done is 
vendor/operator implementation specific, : and out of scope of this patent disclosure). The 

2 0 KeylD is generated by the AAAh and upon successful authentication sent to the MN, which in 

turn sends it to the HA using IKE. 

MIPv6 handoffs use a subset of the MIPv6 initiation procedures described above. For the 
handoff case, since the MN has already been previously assigned a home address and a HA 
25 prior to handoff, EAP/MlPv6 would only need to carry information that facilitate MIPv6 
authentication, and distribution of security keys between PAC and PAA for PANA security. 
The MIPv6 authentication which takes place is for authentication to use the newly acquired 
CoA. As with the MIPv6 initiation case, Diameter protocol is used by AAAh for assignment 
to PAA/EP of optional MIP packet filters via some kind of MIP filter rule, security keys for 

3 0 PANA security, and optional QoS parameters etc. 

When both EAP/AKA for WLAN access authentication, and EAP/MIPv6 have to be carried 
out, it is proposed to allow single traversal to cany out both simultaneously to save time and 
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facilitate fast handoff (both AAAv and AAAh arc traversed), PANA is used in carrying 
EAP/MIPv6 between PAC and PAA/AAA Client. PANA can also used for transporting 
EAP/AKA between PAC and PAA for WLAN access authentication instead of [10]. By 
carrying multiple EAP sequences in a single PANA sequence, both EAP/AKA for WLAN 
5 authentication and EAP/MIPv6 can take place within a single PANA sequence for 
optimization purposes. 

New EAP attributes and exemplary signal flows 

In this section, implementation features of the proposed authentication protocol according to 
10 the invention will be described! Examples of EAP/MIPv6 protocol details are provided to 
show the overall flow and viability of concept. 

The authentication method of the invention involves new EAP TLVs canying information that 
facilitates MIPv6 authentication, dynamic MN home address allocation, dynamic HA 
1 5 allocation, distribution of security keys between HA and MN, and distribution of security keys 
between PAC and PAA for PANA security. 

The following new EAP TLVs are preferably defined under EAP/MEPv6: 





I) 


MD5 Challenge EAP-TLV attribute 


20 


») 


MD5 Response EAP-TLV attribute 




Hi) 


MIPv6 Home Address Request EAP-TLV attribute 




iv) 


MIPv6 Home Address Response EAP-TLV attribute 




v; 


MIPv6 Home Agent Address Request EAP-TLV attribute 




vi) 


MIPv6 Home Agent Address Response EAP-TLV. attribute 


25 


vii) 


HA-MN Pre-shared Key Generation Nonce EAP-TLV attribute 




viii) 


IKE KeylD EAP-TLV attribute 




ix) 


HA-MNIPSecSPI EAP-TLV attribute 




*) 


HA-MN IPSec Key Lifetime EAP-TLV attribute > 




xi) 


PAC-PAA Pre-shared Key Generation Nonce EAP-TLV attribute 


30 







By means of (some or all of) these attributes, the EAP protocol can, in addition to the main 
IPv6 authentication information, carry MBPv6-re)ated auxiliaiy information, which is a 
considerable advantage. The MIPv6-related auxiliary information can e.g. comprise requests 
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for dynamic MN home address allocation, dynamic Home Agent allocation, as well as 
nonces/seeds for creation of necessary security keys. _ 

Different authentication protocols are possible fox EAP/MIPvo. A preferred embodiment of 
the invention proposes implementation through MD5-Challenge authentication, but other 
protocols also lie within the scope of the invention. The following EAP-TLV attributes are 
defined for MlPv6 authentication: 

i) MD5 Challenge EAP-TLV attribute 

This represents the octet string generated randomly by the AAAh and sent to. MN for MD5 
challenge. 



U) MD5 Response EAP-TLV attribute 

This represents the octet string generated as a result of MD5 hash function with the shared 
15 secret key between AAAh and MN. 

The following EAP-TLV attributes are preferably defined for dynamic MN home address 
allocation: 

20 Hi) MIPv6 Home Address Request EAP-TLV attribute 

This represents a request for a dynamically allocated MlPv6 home address for the 
authenticated MN. It will be requested by the MN to the AAAh when the MN .niUally 
requests to be authenticated and given MIPv6 service. This attribute ^optional when the MN 
already has a previously assigned home address, e.g., during MIPv6 handoffs. 

25 

iv) MIPv6 Home Address Response EAP-TLV attribute 

This represents a dynamic allocated MIPvo home address for Ore authenticated MN. It will be 
notified to the MN from AAAh when the MN, which has requested for one, .has been 
successfully authenticated. This attribute is optional when the MN already has a previously. 
3 0 assigned home address, e.g., during MIPv6 handoffs. 

The following EAP-TLV attributes are preferably denned for dynamic HA allocation: 
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vj MPvd /fomtf /Igewf Address Request EAP-TLV attribute 

This represents a request for an address of a dynamically allocated HA for the MN when 
successfully authenticated. It will be requested by the MN to the AAAh when a MN initially 
requests to be authenticated and given MIPv6 service. As the MIPv6 protocol has a dynamic 
HA discovery method to allocate the HA, this attribute is optional. This is also the case when 
the MN already has a previously assigned HA, e.g., during MlPv6 handoffs. 

vi) MIPv6 Home Agent Address Response EAP-TLV attribute 

i 

This represents an address of a dynamic allocated HA for the authenticated MN. It will be 
notified to the MN from the AAAh when a MN initially requests to be authenticated and given 
MIPv6 service. As the MlPv6 protocol has a dynamic home agent discovery method to 
allocate the home agent, this attribute is optional. This is also the case when the MN already 
has a previously assigned HA, e.g., during MIPv6 handoffs. 

The following EAP-TLV attributes are preferably defined for distribution of security keys 
between HA and MN: 

viij HA-MN Pre-shared Key Generation Nonce EAP-TLV attribute 

This represents the octet string generated randomly by MN as a seed for generating the pre- 
shared key between HA-MN. The MN can internally generate the HA-MN pre-shared key by 
using an appropriate hash algorithm on the combination of this nonce and the shared key 
between MN and AAAh. This attribute is optional when a valid HA-MN pre-shared key 
already exists, e.g., during MIPv6 handoffs, 

viii) IKE KeylD EAP-TLV attribute " 

This represents the ID payload defined in [7). The KeylD is generated by the AAAh and sent 
to the MN upon successful authentication. The KeylD includes some octets which informs the 
HA how to retrieve (or generate) the HA-MN pre-shared key from AAAh. This attribute is 
optional, and would generally not be needed when the MN did not submit a HA-MN pre- 
shared key generation nonce, i.e., a valid HA-MN pre-shared key already exists, e.g., during 
MIPv6 handoffs. It is also not needed for the case when the HA-MN pre-shared key is 
conveyed by the AAAh to the HA via the AAAh-HA interface defined in [2J. 
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ix) HA-MN IPSec SPI EAP-TLV attribute 

This represents the Security Parameter Index for IPSec between the HA and MN. This is 
generated by the HA and informed to the MN for the case when the HA-MN pre-shared key is 
conveyed by the AAAh to the HA via the AAAh-HA interface defined in [2]. This attribute is 
optional and is generally not needed when the MN did nol submit a HA-MN pre-shared key 
generation nonce, i.e., a valid HA-MN pTe-shared key already exists, e.g., during MIPv6 
handoffs. It is also not needed for the case when the AAAh-HA interface defined in [2] is not 
used. 

x) HA-MN IPSec Key Lifetime EAP-TLV attribute . 

This represents the Key Lifetime for IPSec between the HA and MN. This is generated by the 
HA and informed to the MN for the case when the HA-MN pre-shared key is conveyed by the 
AAAh tq the HA via the AAAh-HA interface defined La [2]. This attribute is optional and is 
generally not needed when the MN did not submit a HA-MN pre-shared key generation 
nonce, i.e., a valid HA-MN pre-shared key already exists, e.g., during MIPv6 handoffs. It is 
also not needed for the case when the AAAh-HA interface defined in [2] is not used. 

Finally, the following EAP-TLV attribute is preferably defined for distribution of security 
keys between PAC and PAA for PANA security: 

xi) PAC-PAA Pre-shared Key Generation Nonce EAP-TLV attribute 

This represents the octet string generated randomly by MN/PAC as a seed for generating the 
pre-shared key between PAC-PAA. The MN/PAC can internally generate the PAC-PAA pre- 
shared key by using an appropriate hash algorithm on the combination of this nonce and the 
shared key between MN and AAAh. This attribute is needed for PANA security. 

Preferred schemes for handling MIPv6 initiation and handoff according to the invention are 
provided in the signaling flow diagrams Figs. 2, 3 and 4. The illustrated examples relate to 
MIPv6 AAA using a combination of PANA and Diameter as carrier protocols. The flow 
diagram in Fig. 2 illustrates MIPv6 initiation with use of an AAAh-HA interface according to 
[2] for exchange of a HA-MN pre-shared key. Another MIPv6 initiation scheme, illustrated in 
Fig. 3, uses IKE KeylD for exchange of a HA-MN pre-shared key. The signaling flows of Fig. 1 
4 describe MIPv6 handoff in accordance with an exampJary embodiment of the invention. 
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Concluding remarks/Benefits of the invention 

A major advantage of the proposed EAP protocol is that it allows EAP to cany MIPv6-related 
auxiliary information in addition the main MIPv6 authentication information. This auxiliary 
5 information may include requests for dynamic MN home address allocation, dynamic Home 
Agent allocation, as well as nonces/seeds for creation of necessary security keys. The MIPv6- 
related auxiliary information are exchanged between the Mobile Node and AAAh (home 
AAA server), and there is no need for intermediaries like AAA Clients and AAAv (visited 
AAA servers) to understand the information. 

10 ' \ . 

Without the proposed solution, i.e. if EAP was not carrying the MIPv6-related auxiliary 
information, requirements would typically be placed on the carrier protocols like PANA and 
Diameter to cany this information. This leads to an increased complexity of the carrier 
protocols and to compromised security (as the information is also picked up by intermediaries 

15 AAA Clients and A AAv's). 

To sum up, the invention achieves a complete MIPv6 AAA solution f6r the first time, and 
does not put unnecessary complexities on carrier protocols. It also enables security of 
information between the Mobile Node and home AAA server. 

20 

Although the invention has been described with reference to specific exemplary embodiments, 
it also covers equivalents to the described features, as well as modifications and variants 
obvious to a man skilled in the art 
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ABBREVIATIONS 



Tabic 1 below contains a list of abbreviations and acronyms used in this document 



5 Table 1 ; 

AAA - Authentication Authorisation and Accounting 

AAAh - Home AAA 

AAAv - Visited AAA 

AKA - Authentication Key Agreement-" 

EAP - Extensible Authentication Protocol 

EP - Enforcement Point 

HA - Home Agent 

IKE - Internet Key Exchange 

IPSec - IP Security 

ISAKMP - Internet Security Association and Kefy Management Protoa 

MD5 - Message Digest 5 

MIPv6 - Mobile IP version 6 

MN - Mobile Node 

PAA - PANA Authentication Agent 

PAC - PANA Client 

PANA - Protocol for carrying Authenticatioh for Network Access 

SPI - Security Parameters Index 

TLS - Transport Layer Security 

TLV - Type Length Value 

TTLS- Tunneled TLS 

WLAN - Wireless Local Area Network 
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ABSTRACT 

The present invention proposes on authentication method for mobile IP communication, 
which enables MIPv6 AAA, for example through a combination of PANA and Diameter as 
carrier protocols. A new EAP authentication protocol is provided that can carry information 
facilitating MIPv6 authentication, dynamic MN home address allocation, dynamic HA 
allocation, distribution of security keys between HA and MN> and distribution of security keys 
between PAC and PAA for PANA security. The protocol preferably defines a number of new 
TLV attributes for carrying this kind of information. 
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